-
Notifications
You must be signed in to change notification settings - Fork 982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cookie-based auth #1521
Cookie-based auth #1521
Conversation
c49b0d8
to
38f7ea9
Compare
There's currently E2E test failures in:
This is kind of to be expected, given the scale of this refactor. In addition, we need to make sure that files are served from a place which does not have API access, e.g. the files should really be untrusted. Otherwise, an LLM or whoever uploads files could call the Chainlit API on the user's behalf by crafting malicious HTML with JS. To get there, we need to:
This would be a good moment to 'go all in' in terms of file security. We could also postpone this to a later PR and/or explicitly document that files in their current implementation should not come from untrusted sources (e.g. AI-generated or from 3rd parties). |
83a4474
to
441d198
Compare
Just 2 more tests missing:
|
272f985
to
6bc5694
Compare
* Organise imports and formatting. * Log uncaught exceptions in data layer. * Typing cleanup and explicit assertions. * Move auth to module. * Factor out JWT functionality.
* Factor out redundant maybe user creating. * Factor out common user param. * Add a get_user() route to allow access to user data. * Import sorting. * Make using cookies the default. * Refuse to serve files unless we are using cookie auth.
6bc5694
to
4d81a99
Compare
Prevents redundant redirect.
* Header and password auth support. * Consistent typing for useAuth(). * Comment to document useAPI() hook. * Factor out auth types, config, state, settings, session and token management. * Determine auth state based on whether user is set. * Make auth a core component module. * Check `/login/` response for expected output. * Request `/user` when cookieAuth's available. * Use `user` instead of `access_token` to determine whether we're logged in.
* Don't assume errors are always JSON with .detail * Add status to ClientError. * Factor out request error handling. * Consistent handling of errors: either call on401() or throw, never both. * Disable/override on4041 and onError hooks for useApi(). Requests not initiated by the user should not cause user-facing notifications. Plus, 401 on `/user` is now expected behaviour.
* Separate assertions and state preparation. * Check for call on /user for cookie auth. * Test for presence of cookie in login reply.
4d81a99
to
84e88ad
Compare
I hugely appreciate community feedback and/or a security review of the aforementioned options for cookie auth. @hmrc87 @celeriev @willydouhard @robkrause |
|
||
# If no cookie, try the Authorization header as fallback | ||
if not token: | ||
# TODO: Only bother to check if cookie auth is explicitly disabled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we leaving this todo?
user = await config.code.password_auth_callback( | ||
form_data.username, form_data.password | ||
return RedirectResponse( | ||
# FIXME: redirect to the right frontend base url to improve the dev environment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we fix this before RC?
Implementation of #1520